07. Arm Mover
You’ve written your first ROS node! This was no trivial task. You’ve had to learn quite a few things to get to this point. But before you will be prepared for the final project, we have some more ground to cover.
Namely, we still need to cover:
- Custom message generation
- Services
- Parameters
- Launch Files
- Subscribers
- Logging
In order to gain an understanding of some of the above, you will be writing another node called
arm_mover
.
Description of Arm Mover
In many respects,
arm_mover
is quite similar to
simple_mover
. Like
simple_mover
, it is responsible for commanding the arm to move. However, instead of simply commanding the arm to follow a predetermined trajectory, the
arm_mover
node provides the service
move_arm
, which allows other nodes in the system to send
movement_commands
.
In addition to allowing movements via a service interface,
arm_mover
also allows for configurable minimum and maximum joint angles, by using parameters.
Creating a new service definition
As you learned earlier, an interaction with a service consists of two messages being passed. A request passed to the service, and a response received from the service. The definitions of the request and response message type are contained within .srv files living in the
srv
directory under the package’s root.
Let’s define a new service for simple_arm. We shall call it
GoToPosition
.
$ cd ~/catkin_ws/src/simple_arm/
$ mkdir srv
$ cd srv
$ touch GoToPosition.srv
You should now edit
GoToPosition.srv
, so it contains the following:
float64 joint_1
float64 joint_2
---
duration time_elapsed
Service definitions always contain two sections, separated by a ‘---’ line. The first section is the definition of the request message. Here, a request consists of two float64 fields, one for each of
simple_arm
’s joints. The second section contains is the service response. The response contains only a single field, time_elapsed. The
time_elapsed
field is of type duration, and is responsible for indicating how long it took the arm to perform the movement.
Note: Defining a custom message type is very similar, with the only differences being that message definitions live within the
msg
directory of the package root, have a “.msg” extension, rather than
.srv
, and do not contain the “---” section divider. You can find more detailed information on creating messages and services
here
, and
here
, respectively.
Modifying CMakeLists.txt
In order for catkin to generate the python modules or C++ libraries which allow you to utilize messages in your code you must first modify
simple_arm
’s
CMakeLists.txt
(
~/catkin_ws/src/simple_arm/CMakeLists.txt
).
CMake is the build tool underlying catkin, and
CMakeLists.txt
is nothing more than a CMake script used by catkin. If you’re familiar with GNU make, and the concept of makefiles, this is a similar concept.
First, ensure that the
find_package()
macro lists
std_msgs
and
message_generation
as required packages. The
find_package()
macro should look as follows:
find_package(catkin REQUIRED COMPONENTS
std_msgs
message_generation
)
As the names might imply, the
std_msgs
package contains all of the basic message types, and
message_generation
is required to generate message libraries for all the supported languages (cpp, lisp, python, javascript).
Note
: In your
CMakeLists.txt
, you may also see
controller_manager
listed as a required package. In actuality this package is not required. It was simply added as a means to demonstrate a build failure in the previous lesson. You may remove it from the list of REQUIRED COMPONENTS if you choose.
Next, uncomment the commented-out
add_service_files()
macro so it looks like this:
## Generate services in the 'srv' folder
add_service_files(
FILES
GoToPosition.srv
)
This tells catkin which files to generate code for.
Lastly, make sure that the
generate_messages()
macro is uncommented, as follows:
generate_messages(
DEPENDENCIES
std_msgs # Or other packages containing msgs
)
It is this macro that is actually responsible for generating the code.
For more information about
CMakeLists.txt
check out
this page
on the ROS wiki.
Modifying package.xml
Now that the
CMakeLists.txt
file has been covered, you should technically be able to build the project. However, there’s one more file which needs to be modified,
package.xml
.
package.xml
is responsible for defining many of the package’s properties, such as the name of the package, version numbers, authors, maintainers, and dependencies.
Right now, we’re worried about the dependencies. In the previous lesson you learned about build-time dependencies and run-time package dependencies. When
rosdep
is searching for these dependencies, it’s the
package.xml
file that is being parsed. Let’s add the
message_generation
and
message_runtime
dependencies.
<buildtool_depend>catkin</buildtool_depend>
<build_depend>message_generation</build_depend>
<run_depend>controller_manager</run_depend>
<run_depend>effort_controllers</run_depend>
<run_depend>gazebo_plugins</run_depend>
<run_depend>gazebo_ros</run_depend>
<run_depend>gazebo_ros_control</run_depend>
<run_depend>joint_state_controller</run_depend>
<run_depend>joint_state_publisher</run_depend>
<run_depend>robot_state_publisher</run_depend>
<run_depend>message_runtime</run_depend>
<run_depend>xacro</run_depend>
You are now ready to build the package! For more information about
package.xml
, check out the
ROS Wiki
.
Building the package
If you build the workspace successfully, you should now find that a python package containing a module for the new service
GoToPosition
has been created deep down in the
devel
directory.
$ cd ~/catkin_ws
$ catkin_make
$ cd devel/lib/python2.7/dist-packages
$ ls
After sourcing the newly created
setup.bash
, the new
simple_arm
package has now become part of your
PYTHONPATH
environment variable, and is ready for use!
$ env | grep PYTHONPATH
Creating the empty arm_mover node script
The steps you take to create the arm_mover node are exactly the same as the steps you took to create the simple_mover script, excepting the actual name of the script itself.
$ cd ~/catkin_ws
$ cd src/simple_arm/scripts
$ touch arm_mover
$ chmod u+x arm_mover
You can now edit the empty arm_mover script with your favorite text editor.
Let’s move onto the code for
arm_mover
.